Skip to content

Restore the Starlette upgrade lost in a merge - #19

Merged
dabeckham merged 1 commit into
mainfrom
fix/restore-starlette-upgrade
Jul 26, 2026
Merged

Restore the Starlette upgrade lost in a merge#19
dabeckham merged 1 commit into
mainfrom
fix/restore-starlette-upgrade

Conversation

@dabeckham

Copy link
Copy Markdown
Owner

What happened

#15 merged, and the next merge silently undid it.

A branch cut before #15 was merged with a stale view of origin/main and
resolved requirements.txt and app/main.py back to the older content —
without reporting a conflict. The changelog entries survived only because they
were reconstructed by hand at the time. The code did not.

It was invisible in a green test run: the new TemplateResponse(request, name, context) signature works on both Starlette versions, so the migrated call
sites passed against the old pin. The tell was the version banner in the test
run — starlette==0.41.3 where 1.3.1 was expected.

What this restores

Nothing new — #15 re-applied unchanged:

  • fastapi==0.140.0 and an explicit starlette==1.3.1 pin
  • the render() / error_page() helpers and the TemplateResponse migration
  • the canonical-host regression test

See #15 for the advisories and the reasoning.

Verification

Run against main as it now stands, so the upgrade is exercised together
with
the trusted-proxy and groups-claim changes rather than on its own — that
combination had never been tested as one tree until now:

  • Backend suite: 37 tests pass, with starlette==1.3.1 / fastapi==0.140.0
    confirmed installed in the run.
  • Browser end-to-end: 4 tests pass against a staging container built from
    this branch.
  • Live identity provider: the app builds a valid authorization request and
    Authentik accepts it and hands off to its login flow.

Audit of the other four

Checked every changed file from #14, #16, #17 and #18 against main — all
present and intact. #15 was the only casualty.

The Starlette/FastAPI upgrade landed on main and was then silently undone by
the next merge: a feature branch cut before it, merged with a stale view of
origin/main, resolved requirements.txt and app/main.py back to the older
content without reporting a conflict. The changelog entries survived because
they were reconstructed by hand at the time; the code did not, and the loss
was invisible in a green test run because the new TemplateResponse signature
works on both Starlette versions.

Re-applies the original change unchanged: fastapi 0.140.0, an explicit
starlette 1.3.1 pin, the render()/error_page() helpers, and the canonical-host
regression test. Nothing here is new — see the original for the reasoning and
the advisories it clears.

Verified against main as it now stands, so the upgrade is exercised alongside
the trusted-proxy and groups-claim changes rather than on its own.
@dabeckham
dabeckham merged commit 509f60d into main Jul 26, 2026
2 checks passed
@dabeckham
dabeckham deleted the fix/restore-starlette-upgrade branch July 26, 2026 21:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant